\chapter{Planowana architektura rozwiązania}
\label{chap:etap2-architektura}

W~celu realizacji oczekiwanego systemu, zaprojektowano i~przeanalizowano schemat rozwiązania. Zdecydowano się na architekturę klient-serwer w oparciu o~szereg technologii ułatwiających i~przyspieszających budowę aplikacji. Równocześnie wstępnie zrealizowano podstawową wersję systemu, pozwalającą sprawdzić, że rozwiązanie działa. Komunikacja opiera się o~protokół HTTP.

\section{Grafowa baza danych}

W~grafowej bazie danych przechowywane są informacje potrzebne do wyznaczenia planu podróży.

W~wierzchołkach przechowywane są informacje o~stacjach i~przystankach, podstawowa informacja to nazwa przystanku, dodatkowe informację mogą być pomocne, jednak nie są konieczne. Dodanie kolejnych pól w opisie wierzchołka nie będzie wpływało na pracę algorytmu wyznaczania połączenia, dlatego kolejne pola mogą być dodawane w~zależności od potrzeb aplikacji.

Krawędzie grafu przechowują szczegółowe informacje o~połączeniach. Miejsce odjazdu i punkt docelowy określają wierzchołki incydentne z~krawędzią. W~atrybutach krawędzi przechowujemy następujące informacje:
\begin{itemize}
\item numer połączenia,
\item nazwa przewoźnika,
\item typ połączenia -- np.~autobus, pociąg, bus,
\item data początkowa i~końcowa połączenia -- przydatne w~przypadku połączeń okresowych np.~wakacyjnych, świątecznych oraz przy zmianie rozkładu,
\item daty wyłączenia -- daty w których połączenie nie jest realizowane,
\item dni kursowania -- nie wszystkie połączenia obowiązują każdego dnia tygodnia,
\item czas odjazdu,
\item czas trwania,
\item cena.
\end{itemize}

Czas odjazdu przechowywany jest jako liczba oznaczająca ilość minut od godziny 00:00, czas trwania połączenia również wyrażony jest w minutach. Taka forma zapisu informacji pozwala na szybkie obliczanie czasu końcowego i~porównanie z czasem odjazdu kolejnego połączenia.

Numer połączenia pozwala na jego identyfikację, tak by np.~kontynuacja przejazdu od następnej stacji tym samym pociągiem nie była oznaczana jako przesiadka.

Pole ceny nie zawiera informacji o cenie przedstawionej w zł, jest to informacja o algorytmie naliczania opłaty. Przechowywanie dokładnej ceny nie jest możliwe z~powodu konstrukcji kolejowej taryfy opłat. Przykładowo przejazd na odcinku do 40~km kosztuje 11~zł, natomiast przejazd na odcinku 60-80 km 21 zł. Zatem koszt biletu w przypadku dłuższego przejazdu nie jest sumą kosztów przejazdu między stacjami pośrednimi. Alternatywne rozwiązanie mogłoby polegać na zapisaniu w~bazie danych dla jednego pociągu wszystkich możliwych biletów na każde możliwe ,,podpołączenie'', spowodowałoby to jednak olbrzymią redundancję danych. Dodatkowo umieszczenie osobnego konfigurowalnego modułu obliczania cen zostawia możliwość uwzględnia ulg i~promocji.

\begin{figure}
\begin{center}
\includegraphics{figures/grafPrzyklad.png}
\caption{Przykładowe połączenie miedzy stacjami Warszawa Wschodnia -- Warszawa Zachodnia}
\end{center}
\end{figure}

Zostanie użyta baza danych Neo4j, gdyż jest to dojrzałe rozwiązanie, które zespół poznał w~trakcie pierwszego etapu pracy nad projektem. Dodatkowo Neo4j jest jedyną grafową bazą danych wspieraną przez framework Spring\footnote{\burl{http://www.springsource.org/spring-data}}.

Z dwóch podstawowych sposobów użycia Neo4j (\textit{server} oraz \textit{embedded}) wybrano tę drugą opcję. Tryb pierwszy polega na utworzeniu i~uruchomieniu samodzielnego serwera, który udostępnia \textit{REST API} po protokole \textit{http}.  Podejście to pozwala uniknąć tworzenia własnego serwera udostępniającego bazę danych, jednak przez to bezpieczeństwo samej bazy jest zmniejszone.

Użyty tryb \textit{embedded} (wbudowany) pozwala na dostęp do bazy danych z poziomu aplikacji \textit{Java} poprzez podłączenie się do niej. Udostępnione API umożliwia niskopoziomowy, wydajny dostęp do struktur danych w Neo4j, co ułatwia efektywną realizację algorytmów dostosowanych do wymaganych zastosowań.

\section{Użyte technologie}

Poza oczywistym użyciem języka \textit{Java} i~grafowej bazy danych Neo4j do stworzenia aplikacji serwerowej oraz języka \textit{html} i~\textit{JavaScript}, wykorzystano szereg pomocniczych technologii:
\begin{enumerate}
	\item Spring MVC -- framework do zautomatyzowania realizacji serwera oraz mechaniki przetwarzania zapytań do niego,
	\item AJAX (ang. Asynchronous JavaScript and XML) -- umożliwienie edycji wynikowego dokumentu www bez przeładowywania całej jego zawartości na podstawie odpowiedzi serwera,
	\item jQuery -- ułatwia korzystanie z JavaScript oraz manipulację na modelu DOM,
	\item JSON (ang. JavaScript Object Notation) -- definiuje format przesyłanych danych tekstowych,
	\item JSP (ang. JavaServer Pages) -- tworzenie dynamicznych dokumentów HTML z użyciem języka Java,
	\item Apache Tomcat -- kontener aplikacji webowej; serwer, który umożliwia uruchamianie aplikacji internetowych w technologiach \textit{java servlets} i~\textit{JavaServer Pages}.
\end{enumerate}

Końcowemu użytkownikowi udostępniamy stronę internetową, pozwalającą korzystać z~proponowanych funkcjonalności.

%\subsection{Spring}
%\subsection{AJAX}
%\subsection{jQuery}
%\subsection{JSON}
%\subsection{JSP}

\section{Schemat rozwiązania}

W celu realizacji zadanej funkcji, utworzony zostanie serwer realizujący pojedyncze zapytania GET/POST od cienkich klientów za pomocą dynamicznej strony www. Schemat\ref{fig:schemat-technologie} przedstawia typowe przepływy możliwych zapytań. Kolejno wykonywane są następujące czynności:
\begin{enumerate}
	\item Klient wysyła zapytanie GET/POST o stronę lub poprzez wywołanie funkcji JavaScript z udostępnionej strony html z użyciem technologii AJAX.
	\item W przypadku zapytania AJAX tworzony jest XMLHttpRequest wraz z funkcją obsługi odpowiedzi zwrotnej \textit{callback}.
	\item Żądanie HTTP jest przesyłane na serwer, gdzie trafia w pierwszą warstwę mechaniki Spring -- \textit{Front Controller}.
	\item Żądanie jest analizowane i następnie przesyłane do opracowanego i~zaimplementowanego w~Java kontrolera.
	\item We właściwym kontrolerze realizowana jest mechanika aplikacji.
	\item Wykonywane jest ewentualne (jeśli potrzebne) zapytanie do bazy będącej w przyjętym rozwiązaniu integralną częścią Java.
	\item Jeśli nastąpiło zapytanie do Neo4j, baza zwraca obiekty klas domenowych, odpowiadające bezpośrednio obiektom zapisanym w bazie.
	\item Kontroler przetwarza otrzymane dane, tworzy albo prosty model odpowiedzi (zapytania zwykłe GET/POST), albo tworzy strukturę JSON opakowującą dane (zapytania AJAXowe) i wysyła go z powrotem do \textit{Front Controller}.
	\item \textit{Front Controller} przesyła odebrany model albo do zaimplementowanego kodu JSP (jeśli było to zwykłe zapytanie GET/POST i dane wymagają sformatowania do standardu html), lub od razu do klienta.
	\item Mechanika kodu JSP tworzy sformatowaną odpowiedź na podstawie surowego modelu. Tak uzyskaną formę zwraca do \textit{Front Controller}.
	\item \textit{Front Controller zwraca po protokole HTTP odpowiedź do klienta}.
	\item Po stronie przeglądarki klienckiej odbierany jest wygenerowana struktura pliku www (w przypadku zwykłych zapytań) lub wywoływana jest wcześniej utworzona funkcja \textit{callback}, w której przetwarzane są dane oraz używany jest jQuery do manipulacji na obiektach strony html (zapytania AJAX).
	\item Tak zmieniona zawartość strony jest pokazywana użytkownikowi jako wynik całej akcji.
\end{enumerate}

Ważnym elementem założeń projektu jest podział kodu implementowanego kodu \textit{Java} w kontrolerze. Poszczególne grupy klas wyglądają następująco:
\begin{itemize}
	\item Controller -- klasy zajmujące się odebraniem od \textit{Front Controller} zapytania, analizę jego argumentów oraz zwracania odpowiedzi,
	\item Domain -- klasy domenowe odpowiadające dokładnie obiektom w bazie danych,
	\item Import -- klasy służące do importowania danych do Neo4j,
	\item Service -- klasy służące do interakcji i manipulacji na bazie danych; poprzednie klasy nie mogą odnosić się bezpośrednio do Neo4j, a~jedynie poprzez klasy Service.
\end{itemize}

Ze względu na duży stopień skomplikowania mechanizmu, podczas wykonywania projektu dobrze jest korzystać z~poprawnie zrealizowanego i~podobnego architektonicznie rozwiązania\footnote{\url{http://static.springsource.org/spring-data/data-graph/docs/current/reference/html/}}.

\begin{figure}
	\includegraphics{figures/schemat-technologie.jpg}
	\caption{Schemat przetwarzania zapytania z użyciem technologii}
	\label{fig:schemat-technologie}
\end{figure}

\section{Bezpieczeństwo}

Zakładamy systematyczne wykonywanie kopii zapasowych za pomocą konsoli Neo4j \footnote{\url{http://docs.neo4j.org/chunked/stable/backup-embedded-and-server.html}} w~przypadku ewentualnych zmian w serwerze i~bazie danych, lecz z~założenia, baza danych będzie tylko udostępniała dane końcowemu użytkownikowi, a~nie je modyfikowała z powodu zapytań klienckich.

Dostęp do Neo4j jest możliwy tylko poprzez serwer i~warstwę kontrolerów, które skutecznie chronią dane i~nie pozwalają na akcje niezgodne z~przewidywanymi funkcjonalnościami.

\section{Środowisko programistyczne}

Podczas przygotowania projektu niezbędne są pewne biblioteki i~środowiska programistyczne. W~celu uproszczenia oraz przyspieszenia realizacji produktu wykorzystano technologię Maven. Narzędzie to pozwala na zautomatyzowaną budowę aplikacji z~użyciem konfigurowalnego pliku POM (ang. Project Object Model). Dzięki użyciu Maven'a programiści nie muszą pamiętać o tym, jakie biblioteki muszą ściągnąć i zainstalować na swoim komputerze, gdyż Maven robi to automatycznie. Jednocześnie, narzędzie samo sprawdza, czy projekt jest poprawny, kompiluje pliki źródłowe oraz potrafi uruchomić bazę Neo4j. Dalsze funkcjonalności, takie jak wykonywanie testów integracyjnych czy budowanie paczki dystrybucyjnej możliwe jest również automatyczne, z~użyciem dodatkowych paczek Maven'a.

Ze względu na użycie języka \textit{java} oraz technologii Maven, do tworzenia aplikacji nie jest już nic więcej wymagane. W~celu ułatwienia procesu pisania kodu, każdy może korzystać z~dowolnego IDE programistycznego, takiego jak \textit{Ecplise}, \textit{NetBeans} czy też \textit{IntelliJ}.
